@dkuku I'm sorry, but I don't fully understand the purpose of this type in the AyeSQL language. Can you please elaborate? I understand a possible need to parameterize scripts, but I don't think modifying the parser is a good approach.

Sorry, this was an accidental commit. It should not be here. But to explain it - some of the libraries accept a modifier for the query:
-- name: my_query^ means select one similar to Repo.one
-- name: seed# allows to run multiple queries from a file - I'm using this for seeding database for tests in one of my projects. I just don't like the modifier and think that having additional comment makes more sense. Especially that function names with ! have special meaning in elixir.
https://nackjicholson.github.io/aiosql/defining-sql-queries.html
https://github.com/krisajenkins/yesql#insert-returning-autogenerated-keys

I think, for this type of seed file, it's better to leverage other stuff like EEx templates instead of AyeSQL parser. Mainly, because you can still parameterize them using the assigns (see more here) and you don't really need functions at run time for the seeds, so they could be simply uncompiled elixir scripts (similar to the scripts used in Ecto) e.g. so if we have the following file:

-- ./priv/my_seeds.sql.eex
INSERT INTO users (email, password)
VALUES ('<%= @email %>', '<%= @password %>');

And then load the file in an elixir script like this:

# ./my_seeds.exs
# ... omitting Ecto.Repo config ...

assigns = [
  username: "[email protected]",
  password: "whatever" |> :crypto.hash(:sha256) |> Base.encode16()
]

seeds =
  "./priv/my_seeds.exs"
  |> File.read!()
  |> then(&EEx.eval_string(&1, assigns: assigns))

# The run a transaction with the raw SQL statement in the variable `seeds`.

Finally, you could run everything with mix run or elixir commands.

@dkuku There are several reasons why I don't think modifying the parser is a good approach (see my following comments):

@dkuku There's parsing outside of the parser for a specific case. This should be handled somehow inside the parser in case it needs to be supported. This raises new questions though:

• Should we split the parser between normal and script types?
• Show script types accept more than one script (so more than one generated function) from the same file?

If we wan't to implement this feature it needs some discussion around it. And be wrapped in transaction. The blocker I had was that transactions are differently named in postgres comparing to mysql so this would need to be somehow configurable.

In this case, you can rely on Ecto.Repo.transaction/2. Those are general enough that do not care about the underlying database.

@dkuku Splitting a statement with ; and then running each statement by itself makes the script operation unsafe as it doesn't happen inside a transaction.

Instead of this change, wouldn't it be better to use an actual script and use Postgrex or Ecto's APIs to do the sustitution?